[#1074] Keep what says the connection is gone through the redaction of a connect failure - #1107

praise: The rebuild now carries what says the connection is gone, and it asks the classifier's own question to decide that.

• droppedTail() asks JDBCStorage.saysTheConnectionIsGone(), now package-private, rather than a second copy of the rule.
• testALongChainThatSaysNothingOfTheConnectionIsNotMadeToSayItByTheRebuild guards the other direction too: the cut makes no failure a drop.
• sameKind() checks each subtype before its supertype: the three connection types come first, and SQLTimeoutException / SQLTransactionRollbackException come before SQLTransientException.

suggestion (non-blocking): Only the next-exception cut is pinned. The cause cuts, the suppressed cut and the walk's cause/suppressed enqueues are not.

opendj-server-legacy/src/main/java/org/opends/server/backends/jdbc/CachedConnection.java:2239, :2301, :2364, :2344-2346

Every new fixture (plainChain, deepChain) is chained with setNextException only, so the gone link is always reached through the :2235 arm. redactedCopy() rebuilds the next chain first, then the cause, then the suppressed. On a next chain of 32+ links, the budget is therefore spent before the head's own cause and suppressed are reached. The suppressed case is where establish() puts the 08003 close failure (#929). If droppedTail(Collections.<Throwable>emptyList()) is put at :2239, :2301 or :2364, or the cause/suppressed enqueue is dropped from firstLinkSayingTheConnectionIsGone(), #1074 comes back on those edges and the suite stays green. The older long cause chains (CachedConnectionTestCase:888/:910/:930) are 08006 at every link and never call isConnectionFailure. I established this by reading, not by running the mutant.

	@Test(timeOut = 60000)
	public void testALinkThatSaysTheConnectionIsGoneOnACauseOrASuppressedEdgePastTheBudgetStillSaysSo()
			throws Exception {
		final String url = "jdbc:postgresql://127.0.0.1:5432/opendj";
		final SQLException byCause = plainChain(40);
		byCause.initCause(new java.io.IOException("socket closed", new SQLException("connection reset", "08S01", 10054)));
		final SQLException bySuppressed = plainChain(40);
		bySuppressed.addSuppressed(new SQLException("the connection is closed", "08003"));
		for (final SQLException failure : new SQLException[] { byCause, bySuppressed }) {
			final SQLException reported = CachedConnection.reported(failure, url);

			assertNotSame(reported, failure, "a chain this long is expected to be rebuilt");
			assertTrue(JDBCStorage.isConnectionFailure(reported),
				(failure == byCause ? "the cause" : "the suppressed") + " cut past the budget no longer says the connection is gone");
		}
	}

Pin: byCause turns red under an empty rest at :2239 and under a dropped cause enqueue; bySuppressed turns red under an empty rest at :2301. Both are green at this head.

suggestion (non-blocking): Only the three connection arms of sameKind() are pinned. Any of the other nine can be deleted or reordered with every test still green.

opendj-server-legacy/src/main/java/org/opends/server/backends/jdbc/CachedConnection.java:2252-2289

The only typed exceptions that go through reported() in a test are the three at CachedConnectionTestCase:956. The arms are not free of behaviour. Delete the SQLTimeoutException arm and a driver timeout on a url with a password becomes a SQLTransientException. It then takes the warn arm of borrowedOrShared() (JDBCStorage.java:7104) instead of the debug one, which the same failure takes on a url without a password.

	@Test(timeOut = 60000)
	public void testEveryStandardTypeOfALinkIsKeptThroughRedaction() throws Exception {
		final String url = "jdbc:postgresql://opendj:S3cretOfTheBackend@127.0.0.1:5432/opendj";
		final String message = "login to " + url + " failed";
		for (final SQLException original : new SQLException[] {
				new SQLTimeoutException(message, "HYT00", 0),
				new java.sql.SQLTransactionRollbackException(message, "40001", 1205),
				new java.sql.SQLFeatureNotSupportedException(message, "0A000", 0),
				new java.sql.SQLIntegrityConstraintViolationException(message, "23000", 2627),
				new java.sql.SQLInvalidAuthorizationSpecException(message, "28000", 18456),
				new java.sql.SQLSyntaxErrorException(message, "42000", 0),
				new java.sql.SQLDataException(message, "22000", 0),
				new java.sql.SQLTransientException(message, "S1000", 0),
				new java.sql.SQLNonTransientException(message, "S1000", 0) }) {
			final SQLException reported = CachedConnection.reported(original, url);

			assertNoCredentials(reported);
			assertEquals(reported.getClass(), original.getClass(), "the rebuild changed the type of the link");
		}
	}

Pin: deleting any one of the nine arms turns this case red.

suggestion (non-blocking): The direct-throw deep-chain case does not check that the refusal took the direct road.

opendj-server-legacy/src/test/java/org/opends/server/backends/jdbc/CatalogConnectionTestCase.java:703

The case catches a plain SQLException, and that also admits the SQLTimeoutException of catalogConnectTimedOut(), whose cause is reported(last) and carries the same tail. Suppose 08S01 or 10054 becomes worth retrying for POSTGRES. The connect then retries to the 60 s deadline, the case still goes green, and nothing exercises the direct throw at JDBCStorage.java:2135 any more. The interrupt case of the same file guards its road at :335.

		} catch (SQLException expected) {
			assertFalse(expected instanceof SQLTimeoutException,
				"the refusal was retried to the deadline instead of being reported at once");

suggestion (non-blocking): firstLinkSayingTheConnectionIsGone() walks the chain a second time. The predicate is shared, but the walk is not.

opendj-server-legacy/src/main/java/org/opends/server/backends/jdbc/CachedConnection.java:2329, JDBCStorage.java:4844, :4888

The PR makes saysTheConnectionIsGone() package-private so that "a second copy of the question would [not] drift", but it copies the walk around it. isConnectionFailure() goes through firstLinkMatching(…, WITH_THE_RELEASE, EVERY_LINK, …) into walkLinks(), whose javadoc calls it "the single traversal of this class". The two give the same yes/no today. A later change to the edges of walkLinks() would change what write() reads and leave what the tail carries as it was.

	// JDBCStorage
	static SQLException connectionFailureLink(Throwable failure) {
		return firstLinkMatching(failure, WITH_THE_RELEASE, EVERY_LINK, JDBCStorage::saysTheConnectionIsGone);
	}

	static boolean isConnectionFailure(Throwable failure) {
		return connectionFailureLink(failure)!=null;
	}

    // CachedConnection.droppedTail(rest), in place of firstLinkSayingTheConnectionIsGone(rest)
    SQLException gone = null;
    for (final Throwable t : rest) {
        gone = JDBCStorage.connectionFailureLink(t);
        if (gone != null) {
            break;
        }
    }

issue (non-blocking): The borrowedOrShared() javadoc still says that a failure naming the credentials is rebuilt as a plain SQLException.

opendj-server-legacy/src/main/java/org/opends/server/backends/jdbc/JDBCStorage.java:7077-7079

Since sameKind() (CachedConnection.java:2230), the rebuild keeps the standard JDBC type. A driver SQLTimeoutException on a url with a password now takes the debug arm at :7104, not the warn arm. The paragraph's conclusion still rests on #1011; only this premise is out of date.

		 * a driver of no known dialect has no vendor code read at all (issue #1011). The type is no
		 * rule either: a driver need not raise the standard JDBC type that names what happened, and a
		 * failure whose chain names the credentials of the backend keeps only that standard type, not
		 * the class of the driver (#1074). Sorting them here would be that